RFC 6749（The OAuth 2.0 Authorization Framework）を読む会をしました

社内でRFC 6749を読む会をやりました

#OAuth 2.0

稲葉純

2021.07.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

現在私は barista という OpenID Connect と OAuth2.0 に準拠した ID 製品の実装を行っています。また、私の所属する Prismatix 事業部では prismatix というEC、CRM の API 製品の開発を行っていますが、この prismatix の認可サーバーとして barista を利用しています。

RFC 6749 - The OAuth 2.0 Authorization Framework を読む会

以前雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本を読む会を行ったのですが、今回はRFC 6749 - The OAuth 2.0 Authorization Framework を読む会をしました。

勉強会ではOpenID Foundation Japan による日本語訳を利用させていただきました。

狙い

開催にあたっての目標は以下としました。

RFC 6749 に書いてあることを一通り、何となくでも理解する
何らかの RFC を読んだことがあるメンバーを増やす
参加者に「RFC、読もうと思えば読めるじゃん」という感覚を持ってもらう

読書会

以下のようにして読書会を進めました。

ある程度区切りを決めて各自勝手に読み進める
読書会用に Slack のチャンネルを用意してわからないところができれば都度質問
全員がある程度読み進めたら日時を調整して会を開催
- 疑問が残っていればここで解消
- 事前に準備した問題集を使って理解度を確認

前回の勉強会同様、ややこしい部分や各グラントタイプのシーケンスを参加メンバーに実際に書いてもらう形で会を進めました。今回はツールとして Cacoo を利用させていただきました。

シーケンス図

また、以下の全5回に分けて行いました。

やってみてどうだったか

もともとある程度 OAuth 2.0 を理解していたメンバーが参加してくれたのですが、よく知らないグラントタイプであったりプロトコルにおけるいろいろな制約の意義を理解する、といったところでそれなりに有意義な会だったのではないかなと思います。完全な初学者が参加する場合、いきなり RFC を読んでいくとちょっと辛いと思うので雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本や、その他の資料である程度前提知識をつけたほうがよいかもしれません。

また、同じアプリケーションを開発している近いロールのメンバーだけではなく違うチームのメンバーも参加してくれたのですが、普段作っているようなアプリケーション前提ではない場合に仕様をどう解釈したらよいのか？という観点での話が出来たのが個人的に面白かったです。

ちなみに2020年4月4日に初めて2021年7月20日に完走しました。各自読んだら開催、ではなく毎週開催してその場で読む、のほうがよかったかもしれません。

個人的には Security Considerations を読み直して理解があやふやだったところがいくつかあったので復習になってよかったです。

勉強会で使った問題集

引用元はすべて OpenID Foundation Japan による日本語訳となります。

第1回 1. はじめに

RFC6749 で説明しているリソースオーナーがサードパーティアプリケーションにクレデンシャルを共有することの問題と制限とは？
OAuth で定義されている4つのロールについて、各ロールの役割とは？
認可グラントとは？
インプリシット、何が暗黙なの？
リソースオーナーのクレデンシャル（ログイン用ID/PW）を直接サードパーティアプリケーションに保存するケースと比べて、リソースオーナーパスワードクレデンシャルのメリットは？
アクセストークンとは？
リフレッシュトークンとは？

第2回 2. クライアント登録、3. プロトコルエンドポイント

クライアントタイプ2つとそれぞれの違いについて説明せよ
サードパーティアプリの実装がスマホアプリと Web アプリの2つあり、前者はパブリック、後者はコンフィデンシャルなクライアントである場合、どのようにクライアントを登録すべきか？
2.3.1 クライアントパスワードの以下の対策としてどのようなものが考えられるか。
- > クライアント認証方式にパスワードが含まれるので, 認可サーバーはクライアント認証を行うすべてのエンドポイントでブルートフォースアタック対策を行わなくてはならない (MUST).
認可エンドポイントは何のために利用されるか？
クライアントが認可エンドポイントを通じて認可サーバーに送信する response_type とは何か？
リダイレクトエンドポイントは何のために利用されるか？
本仕様でインプリシットグラントを利用しないコンフィデンシャルクライアントがリダイレクトエンドポイントの事前登録を必須としないのはなぜか？
認可サーバーがクライアントのリダイレクトエンドポイントを知る方法は？
トークンエンドポイントは何のために利用されるか？
トークンエンドポイントへのリクエスト時にクライアント認証を行う意義は？
アクセストークンのスコープとは？

第3回 4. 認可の取得

認可コードグラントをシーケンスを用いて説明せよ
同じ認可コードで複数回アクセストークンを引き換えようとした場合、認可サーバーはどうすべきか？
認可サーバーはリソースオーナーがアクセス要求を拒否したり、その他の理由で認可リクエストに対するエラーをリダイレクトURIのクエリコンポーネントで表現するが、リダイレクト URI 自体に問題（許可されていなかったり、リダイレクト URI が未指定）があってエラーにする場合、どうすべきか？
認可コードグラントにおけるアクセストークンリクエストで、認可サーバーはクライアントおよびリクエストされた認可コードに対してどのような検証を行う必要があるか？
インプリシットグラントをシーケンスを用いて説明せよ
インプリシットグラントではアクセストークンがユーザーエージェントから参照できるが、認可レスポンスの URI をホストしているサーバーからは参照できない。なぜか？
リソースオーナーパスワードクレデンシャルグラントをシーケンスを用いて説明せよ
クライアントクレデンシャルグラントをシーケンスを用いて説明せよ

第4回 5. アクセストークンの発行、6. アクセストークンの更新、7. 保護されたリソースへのアクセス

リフレッシュトークンがあると何が嬉しいのか？
リフレッシュトークンによるトークン更新の際、scopes を指定できるがこのスコープはすでにリソースオーナーが認可済みのものしか指定できない。その時点で未認可のスコープに対して認可済みのアクセストークンを取得するためにクライアントはどのような対応ができるか？
トークンの更新時にスコープを再度指定でできる。これによってリフレッシュトークンを最初に発行したときに指定した scopes とは異なるスコープのリフレッシュトークンを要求できる。異なるスコープを指定してトークンを更新した際に発行されたリフレッシュトークンのスコープは、最初に発行されたリフレッシュトークンのスコープと同一になるか？
リソースサーバーは保護されたリソースに対してアクセストークンを使ったリクエストが来た際にどのような検証をするか？（RFC の範囲でよい）
リソースサーバーによるアクセストークンの検証はどのような手段が考えられるか？

第5回 8. 仕様の拡張性、9. ネイティブアプリケーション、10. Security Considerations

10.1 の以下はなんのことを言っているのか？
- > クライアント認証が不可能な時には, 認可サーバーはクライアントのアイデンティティ検証のために他の手段を採用すべきである (SHOULD). 例えば, クライアントのリダイレクトURIの登録要求やリソースオーナーによるアイデンティティ確認が考えられる. 有効なリダイレクトURIは, それ単体でリソース所有者の認可時にクライアントのアイデンティティを証明するには至らないが, リソースオーナーの認可取得後に偽のクライアントにクレデンシャルを配布するのを回避するのに利用することができる.
10.2 の以下で語られている、クライアント認証できない場合にリダイレクト URI の登録が MUST となるのはなぜか？
- > クライアントが本質的に認証不可能な場合は, 認可サーバーは認可レスポンス時に用いられる全リダイレクト URI の登録を要求しなければならず (MUST), また上記のような悪意あるクライアントからリソースオーナーを保護する何らかの方策を取るべきである (SHOULD).
10.5は何を意味しているか？
- > 認可コードはプロセスを完了するために, 認可サーバーで権限を付与したリソースオーナーがクライアントへ返却されるリソースオーナーと同じであることを確認するために利用されるプレーンテキストの可搬クレデンシャルとして動作する. したがって, もしクライアントが自身のリソースオーナー認証を認可コードに依存する場合は, クライアントのリダイレクトエンドポイントはTLSの利用を必須としなければならない (MUST).
10.6. 認可コードリダイレクト URI の操作について、シーケンスを用いてどのような攻撃か説明せよ
10章で言及されている ROPC のリスクとは？
「10.16. インプリシットフローにおけるリソースオーナーなりすましのためのアクセストークン不正利用」で紹介されている攻撃について、シーケンスを用いて説明せよ
state で csrf を防ぐ仕組みをシーケンスを用いて説明せよ
オープンリダイレクタとは何か